Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MSC1840: Typed rooms #1840

Closed

Conversation

jfrederickson
Copy link

@jfrederickson jfrederickson commented Feb 3, 2019

Rendered

Signed-off-by: Jonathan Frederickson jonathan@terracrypt.net

FCP tickyboxes

@jfrederickson jfrederickson changed the title Typed rooms MSC1840: Typed rooms Feb 3, 2019
Signed-off-by: Jonathan Frederickson <jonathan@terracrypt.net>
@anoadragon453
Copy link
Member

One alternative to a new state event is just adding a new field into the m.room.create's creation content.

@jfrederickson
Copy link
Author

That would preclude changing the type of a room after creation, right? Then again that may be desirable... not sure.

@anoadragon453
Copy link
Member

Indeed, but yes not sure if the usecase requires such an ability. I at least don't see it for the profiles or communities as rooms use case.

But I'll leave it up for others to chime in.

@jfrederickson
Copy link
Author

jfrederickson commented Feb 3, 2019

I can think of one in particular: this might also be useful for distinguishing between IM-style rooms and long-form style rooms. (Think Matrix as an email protocol for example.) I think it might make sense for a room to change types down the line between two text messaging use-cases.

This might also be useful for Fractal's Banquet/Barbecue split, though I'm less sure about that one.

I did have another thought though... would it make sense for rooms to have multiple types?

@turt2live turt2live added proposal-in-review proposal A matrix spec change proposal labels Feb 3, 2019
@Half-Shot
Copy link
Contributor

I'd argue for not putting more things into m.room.create unless it MUST be a static value for the limetime of the room i.e. version. Anything that could change should be it's own state. I can see reasons to want to change the type at some point.

@jcgruenhage
Copy link
Contributor

What do people think about having multi purpose rooms? For example if a room is used for hosting a git project in matrix, using the same room for discussion about that project would be desirable, because it allows us to use the same alias there.

to specific room types, but that feels like it's beyond the scope of
this proposal at this point.

## Examples
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the type is omitted, would we consider m.room_type.messaging to be the default type given Matrix's history.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be wrong for this part of the spec to state a default value unconditionally. Concretely, it would be wrong for a general purpose library or SDK to report an unconditionally specified default value when the type is omitted.

A typical IM client, working with typical existing IM rooms, will presumably by default (when the type is unspecified) assume it's an IM messaging room; whereas the default assumption in an IoT client will be something else; and there could be deployment scenarios where all rooms have an explicit room type and no default is needed and the client software developed for that scenario reports an error or ignores the room if no type is provided.

A default value is in the eye of the beholder, not absolute.


## Solution

The proposal is to add a new state event, `m.room.type`, to define the
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I realise this may bloat the proposal, but I feel like we should define a few common types in the spec and how clients should react to them, at least at a high level. I.e. m.room_type.messaging should present users with a chat-room like interface, wheras m.room_type.iot.* may just show a simplified view.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe a type like m.room_type.nsfw could be used to filter out explicit content. In that case, would it make sense to allow public directory filtering by room type?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Marking something as nsfw is more like a tag than a type IMO, because you can have nsfw content in different types of room. I think nsfw tagging (or content notices/warnings to be more generic) are a separate topic.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Counter-examples are useful too. It's worth included a counter-example like this in the spec to illustrate one of the boundaries of applicability.

Copy link
Author

@jfrederickson jfrederickson Oct 28, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added a few examples.

For what it's worth... nsfw might still be a useful type to have if it's possible to have multiple types associated with a room? In other words, rather than:

"content": {
    "type": "m.messaging"
}

Use an array:

"content": {
    "types": ["m.messaging", "m.nsfw"]
}

...though regardless of the types in particular, I'd like to consider the option of a types array. @jcgruenhage brought this up outside of a thread, and I think I agree with it:

What do people think about having multi purpose rooms? For example if a room is used for hosting a git project in matrix, using the same room for discussion about that project would be desirable, because it allows us to use the same alias there.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Allowing multiple types at once would cause massive confusion especially in clients which denormalize data. Imagine a room marked as IoT, Messaging, a Matrix Space and a User Profile room, how do you store anything and what do you even render?

@n1trux
Copy link

n1trux commented Jan 20, 2020

What do people think about having multi purpose rooms?

Could that be achieved by setting a "default message type" and have other (non-chat) clients send other events/messages which aren't shown by a chat client?

There could be a difference between "allowed message types" and "room type" aka "default message type" – for example m.room.type.allowed, m.room.type.disallowed, m.room.type.default instead of a "single" room type. This could also be used for @KB1RD's idea of having NSFW messaging allowed/disallowed, possibly with added metadata like proposed by #1767.

There could also be a permissions/tag system for posting messages of different kinds, e.g. "only devices with tag iot or power level ≥50 can post m.message_type.iot". Is there an MSC for tagging users apart from power levels?

@jfrederickson
Copy link
Author

I'd like to point out that some possible room types are independent of the message types meant to be used within them. For example, if room types were used to separate small group chats from larger collaborative chats (think Fractal's Banquet vs. Barbecue), the messages in each would be m.room.messages, but the room type could be used to filter out certain chats from certain clients.

Similarly, if you were to use Matrix for an email-style asynchronous chat interface, the messages may also be m.room.messages, but you might not want to show all the chat-style messages in that client (and vice-versa).

@Sorunome
Copy link
Contributor

It might be a good idea to also add this to the invite state events, which are sent along if you invite somebody

@jcgruenhage
Copy link
Contributor

I'd love to see this happening, and considering it's quite a small change, could this maybe be squished in soon?

@Sorunome
Copy link
Contributor

Sorunome commented Jun 2, 2020

If extensible profiles as rooms is "type:core", shouldn't this also be "type:core", as the entire point of this MSC is to flag different-kind rooms? And, well, this is a core function needed if, well, as newvector seems to want to push matrix, that matrix is more than just a chat....you need typed rooms for that, then.

@anoadragon453
Copy link
Member

@Sorunome Typed rooms are not a hard requirement of extensible profiles. It's possible to point at a generic room, say "this is my profile room", and have everything work. Alternatively you could simply say !andrewm:amorgan.xyz is my profile room.

There are lots of different ways to solve that particular problem. When this MSC was labelled, it was determined that it wasn't a hard requirement of any current "core" MSCs.

@Sorunome
Copy link
Contributor

Sorunome commented Jun 2, 2020

@anoadragon453 and then there will be bug reports of the profile room showing up in your normal chat rooms....

@turt2live
Copy link
Member

Not if we fix peeking first.

@Sorunome
Copy link
Contributor

Sorunome commented Jun 2, 2020 via email

@turt2live
Copy link
Member

Possibly, though all this feedback is on the wrong MSC and not in a thread.

@MurzNN

This comment has been minimized.

@grinapo

This comment has been minimized.

@aledomu

This comment has been minimized.

@karmanyaahm
Copy link

I had an idea kind of like the following, and it would be really nice if room types became a thing in Matrix

A project wants to use Matrix to allow a user to interact with an
IoT lightbulb, but doesn't want the rooms and control messages used
for this to clutter up the user's Element room list
(com.example.manufacturer.iot.light)

@bleonard252
Copy link

Room types are now in the spec

@clokep
Copy link
Member

clokep commented Jun 16, 2024

Room types are now in the spec

I think with them being added in MSC1772 we should likely just close this.

@mscbot fcp close

@mscbot
Copy link
Collaborator

mscbot commented Jun 16, 2024

Team member @clokep has proposed to close this. The next step is review by the rest of the tagged people:

Once at least 75% of reviewers approve (and there are no outstanding concerns), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for information about what commands tagged team members can give me.

@mscbot mscbot added proposed-final-comment-period Currently awaiting signoff of a majority of team members in order to enter the final comment period. disposition-close labels Jun 16, 2024
@turt2live
Copy link
Member

This MSC is not really the same as the room types which are in the spec. In the spec, room types are immutable - this can cause problems with some features.

I'd prefer to see the author's arguments for mutable room types be expanded. -0.8 in favour of FCP.

@dbkr
Copy link
Member

dbkr commented Jun 18, 2024

I agree, there's semantic overlap with the type for rooms the spec already has, and given the discussion of whether NSFW would be a use for this, it seems the intent isn't very clear.

@richvdh
Copy link
Member

richvdh commented Jun 18, 2024

If @jfrederickson (or some other volunteer) is still keen to pursue this and has usecases in mind that aren't well served by the room types in the spec, very happy to see this be updated and kept open.

Assuming that's not the case, I think we should close it to reduce noise and confusion.

@uhoreg
Copy link
Member

uhoreg commented Jun 18, 2024

I agree with Rich. The examples given in this MSC look like they can be served by the room type that is currently specced. And while the semantics of the room type in this MSC and the specced room type are not the same (e.g. with regards to immutability, additional properties, etc.), I think we'd need to see a use case that cannot be served by the currently-specced room type as justification for keeping this open. If we do close this and someone does want to do something that can only be handled by this MSC, they can re-propose it.

@ara4n
Copy link
Member

ara4n commented Jul 2, 2024

I'm on the fence on this one, fwiw. I'm not seeing a good argument in the MSC as to why mutable room types are actually needed, and it's not clear that we've missed out enormously over the years for not having them. The UX needed in clients to go and either let users convert rooms between different types, or the confusing UX caused by rooms suddenly winking out of existence as they get converted between different types, feels like avoidable confusion without an obvious use case, given you can always create a room of the right time. It almost feels icky like casting types in C, given the events in the room will suddenly get 'cast' into the new type, potentially creating a whole sort of general mishmash if a room keeps fluxing between types.

On the other hand, 17 people upvoted this as a good idea, so presumably folks did have a use case for this at the time. (In fact, I vaguely remember encouraging jfred to open it in the first place).

So, everyone: this is your last chance to make a case for mutable room types.

@jfrederickson
Copy link
Author

Apologies, meant to respond to this earlier. Personally the currently specified immutable room types are sufficient for the cases I was concerned with, especially since we already have an example of a room type (m.space) that's treated differently by clients. I'm fine with closing this one.

@mscbot
Copy link
Collaborator

mscbot commented Jul 8, 2024

🔔 This is now entering its final comment period, as per the review above. 🔔

@mscbot mscbot added final-comment-period This MSC has entered a final comment period in interest to approval, postpone, or delete in 5 days. and removed proposed-final-comment-period Currently awaiting signoff of a majority of team members in order to enter the final comment period. labels Jul 8, 2024
@mscbot
Copy link
Collaborator

mscbot commented Jul 13, 2024

The final comment period, with a disposition to close, as per the review above, is now complete.

@mscbot mscbot closed this Jul 13, 2024
@mscbot mscbot added finished-final-comment-period and removed disposition-close final-comment-period This MSC has entered a final comment period in interest to approval, postpone, or delete in 5 days. labels Jul 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
finished-final-comment-period kind:core MSC which is critical to the protocol's success needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. proposal A matrix spec change proposal
Projects
Status: Done to some definition
Development

Successfully merging this pull request may close these issues.